home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 18525 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.1 KB
  1. Path: ix.netcom.com!news
  2. From: Bradd W. Szonye <bradds@ix.netcom.com>
  3. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu
  4. Subject: RE: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)
  5. Date: 20 Apr 1996 15:55:36 GMT
  6. Organization: Netcom
  7. Message-ID: <01bb2ed2.425fb900$65c2b7c7@Zany.localhost>
  8. References: <4kk9e1$he1@nntp.Stanford.EDU> <dewar.829276268@schonberg>
  9. NNTP-Posting-Host: det-mi3-05.ix.netcom.com
  10. X-NETCOM-Date: Sat Apr 20 10:55:36 AM CDT 1996
  11. X-Newsreader: Microsoft Internet News
  12.  
  13.  
  14. On Thursday, April 11, 1996, Robert Dewar wrote...
  15. > Chuck said
  16. > 
  17. > "There are a lot of things that are intentionally not spelled
  18. > out by standards.  Sometimes this is because the standard
  19. > writers want to limit the scope of the document to keep it
  20. > legible and usable, and sometimes it's because they don't want
  21. > to preclude implementors from offering usable products
  22. > based on current technology or from adding capabilities and
  23. > value to future products."
  24. > 
  25. > This is a sorry excuse for an obvious oversight if you ask me. All that
  26. > is needed for read is one of the following two sentences:
  27. > 
  28. > The buffer must be long enough to accomodate the data actually read
  29. > 
  30. > or
  31. > 
  32. > 
  33. > The buffer must be at least the length corresponding to the value of
  34. > the count parameter.
  35. > 
  36. > I don't really care which is chosen, I prefer the second but could 
  37. > certainly live with the first, but I do NOT find it acceptable to
  38. > leave this unstated. This kind of carelessness in specification
  39. > which seems endemic in the C runtime library, is bound to lead
  40. > to misunderstandings and portability problems. No one is asking
  41. > for over-specification, or for exhaustive and exhausting formality,
  42. > just for a clear informal statement of what is intended!
  43. > 
  44.  
  45. Try to keep in mind the spirit of defensive programming:
  46. If there's something ambiguous about the way you could implement
  47. something, and one implementation is safe regardless of how you interpret
  48. the ambiguity, the other implementation only works under one specific
  49. interpretation, then defensive programming (and portable programming) will
  50. encourage the code that works under all circumstances. Consider:
  51.  
  52. for (size_t i = 0; i < 10; i++) do_stuff();
  53.  
  54. versus
  55.  
  56. for (size_t i = 0; i != 10; i++) do_stuff();
  57.  
  58. Even though you *know* that i will never be greater than 10, even though
  59. "not equals" should always stop the loop after the tenth iteration,
  60. practically every programmer will write the first loop in preference to
  61. the second. This has nothing to do with standards; the standards say that
  62. i is a local, stack-based variable, not global, and since it is not
  63. volatile or referenced by anything else, do_stuff() couldn't modify it,
  64. even another thread couldn't modify it. But should your memory chips fail,
  65. or do_stuff() accidentally trash the stack with a pointer, then the first
  66. loop will never let i get out of the range of 0 <= i < 10, while the
  67. second loop might.
  68.  
  69. Similarly, defensive/portable/paranoid code (which is what most of us
  70. strive to write) will try to ensure that your buffer is big enough to
  71. support the byte-count given to read. This is no cop-out; this is being
  72. cautious. And there's even a good reason for it: the C run-time is allowed
  73. to pad the end of a file with zero bytes. Just because you *know* that
  74. file is only 68 bytes, you can't rely on getting back only 68 bytes. C can
  75. pad that with zeroes to some system-defined line or page size (this is in
  76. the standard mostly to support mainframe computer text modes). So you
  77. could get back 80 or 132 bytes (the line size of most text files on a
  78. mainframe), 512 or 1024 bytes (the sector size of most files on a PC or
  79. workstation), or 4096 bytes (the memory page size under Win32), or any
  80. value in between, including 68 bytes (what's actually in the file).
  81.  
  82. Now, whether a file is padded with zeroes is implementation-defined, which
  83. means that your compiler manuals need to specify whether this happens. But
  84. it's *intentionally* left out of the standards, not as a cop-out or
  85. silliness, but because of real-world concerns. And it's just one more good
  86. reason to consult your local manuals for C or POSIX and *not* the
  87. standards documents. Standards documents are for vendors, not for
  88. programmers.
  89.  
  90.  
  91.